1. Field of the Invention
The present invention relates to the field of integration of legacy computer data. In particular, the present invention relates to model driven design, and specifically, to the field of data integration of legacy COBOL data structures including dynamic COBOL clauses to object instances for object-oriented computing systems.
2. Description of the Background Art
In recent years, the need has arisen to integrate legacy COBOL data sets stored across one or more COBOL mainframe computing systems to one or more object-oriented computing systems. However, prior art approaches of integrating legacy COBOL data sets stored on legacy COBOL mainframe computing systems to object-oriented computing systems have numerous problems that remain unresolved.
One prior art approach to integrating legacy COBOL data sets operable on COBOL mainframe computing systems to object-oriented computing systems involves transforming the legacy COBOL data sets to an intermediate object-oriented form. Generally, this approach involves extracting a legacy data set from a mainframe database, transforming the extracted legacy data set to an object-oriented form (e.g., an intermediate of XML form), and then loading the transformed object-oriented data set to a unified repository. The transformed data sets can then be accessed and consumed by object-oriented applications having access to the unified repository. However, this prior art approach is time consuming and expensive.
The prior art approach has numerous additional problems. One problem is that the prior art approach is unable to properly represent instances of OCCURS DEPENDING ON clauses without requiring a human programmer to write custom code for each instance of OCCURS DEPENDING ON. Briefly explained, the COBOL programming language allows the programmer to specify COBOL data structures to be manipulated by the COBOL program. The data structure is defined in a COBOL copybook. The copybook is organized by levels. Level 1 is reserved for the ‘root’ data structure or ‘group’. Generally a given file will contain the data for a single level 1 group. A level N group will contain members (fields or sub-groups) at a level M>N (where M is equal to a member level and N is equal to a group level). Members can be defined as level 2 through 49. Each member can optionally declare its number of occurrences (or cardinality) via an OCCURS clause. One feature in COBOL is the OCCURS DEPENDING ON clause, which causes fields or groups to be repeated a variable number of times. Because OCCURS DEPENDING ON clauses cause fields or groups to be repeated a variable number of times, these clauses have the potential to dramatically affect the size of COBOL files. It is therefore important that solutions for integrating legacy COBOL data sets to object-oriented systems properly represent instances of OCCURS DEPENDING ON clauses.
However, the prior art approach is generally unable to identify the controlling field for OCCURS DEPENDING ON clauses or determine the value for each controlling numeric field. The prior art approach is therefore unable to properly represent OCCURS DEPENDING ON clauses without the undue expense of requiring a human programmer to write custom code for each instance of OCCURS DEPENDING ON.
Another problem associated with the above described prior art approach is its inability to properly represent instances of REDEFINE clauses without the undue expense of requiring a human programmer to write custom code for each instance of REDEFINE. The problem with REDEFINE clauses is similar to the problem described above for OCCURS DEPENDING ON clauses. Briefly explained, REDEFINE clauses are generally used as space saving tools. For example, a sales record database might store customer information. When the customer is an organization, its name field might be a single string field of length 80. However, when the customer is an individual, the name field is REDEFINED as a group with a first name (string of length 39), a middle initial (string of length 1) and a last name (string of length 40). However, the above described prior art approaches are unable to identify the stated definitions for REDEFINE clauses. In fact, the COBOL language has no way to declare the discriminant for a REDEFINED member. In the previous example, whether the customer is an individual or an organization is the discriminant for deciding which definition of “name” to use. As a result, the prior art approach is unable to properly represent REDEFINE clauses without the undue expense of requiring a human programmer to write custom code for each instance of REDEFINE.